Subject: RE: Flow Control Issues More)

From: Robin Layland <[email-masked]>
Date: Tue, 20 Jul 93 00:24 GMT

> On the issues of flooding the network with RNR (2*connection) if a circuit has
> problem. While the number could be large the RNR are going out over a LAN,
which
> has high capacity. If the receiving DLSw has problem, it sends a message back
to
> the origining Router about the Circuit (only one message per circuit).  I fell
> the N*connection is acceptable. Trying to decide which sessions (connections)
in
> a curcuit to RNR and which ones not to would require a priority scheme within
> the curcuit which we don't have. May be nice to have one but let try to finish
> the first round and then talk about adding it.
>  
 
>I will try to address this issue with my idea of the terminlogy, but I'm
>not sure how it will end up or if I have misunderstood the question given
>the difference in terminology. Are we trying to manage the remote end
>of a TCP connection through messages across TCP?  I think that watching
>the outbound TCP windows and queues would be enough to know that the
>far side DLS can still receive frames. If the TCP queues fill up, we RNR 
>local LLC2 sessions that use the TCP connections. Can you still send data
>if you issue an RNR?  We can then use the pacing flow control for the
>end-to-end circuit flow control, with possibly the ENTERBUSY/EXITBUSY
>SSP messages for the drastic cases.  

Scott
 
Robin.... There is a problem if one end-station fails or RNR back to the DLSw
router. The first router doesn't know the station can't receive message. These
messages fill up the queue in the last router. How does the far router tell the
first router to RNR just that one end-station or do all end-station get RNR will
the queue is filled up? (It may be in the RFC, I just had trouble finding it).
 
Watching the queues is a nice and easy way. But can the above problem cause
everyone to have problems? If it doesn't lets go with Scotts idea and set a
maximum queue lenght (n*window size), when that is reached start RNR everyone
and throw away all LLC1 traffic? Of couse we need to put in that the router must
be able to receive X message that were in transit between the time the router
started RNR and the end station could stop sending traffic (could be a problem
since you can map a lot of end stations to one connection such as 2370 traffic
to a LAN at a large data center).
 
We may have a way out by having the RNR sent with the Sequence number for the
last data message the router has successfully queued. This would indicate that
all frame received after that sequence number are unacknowledged. We then may
need to send a REJ LPDU  instead of just an RR when we restart traffic but I am
not sure.
 
A station should not be able to send additional data frames after a RNR is
receive. The end-station can send Supervisor frame after an RNR.
 
 Scott : drastic cases : What do you mean by this